The present application is related to wearable mobile payment systems and methods.
Mobile payments generally refer to payment operations performed via a mobile or wearable device. The operations performed via mobile and wearable devices may include electronic commerce transactions, retail purchasing, micropayments, and other daily payments. Mobile payments may utilize credit cards, debit cards, gift cards, and virtual currencies. While mobile payments facilitate and stimulate the trade, the procedure of providing financial details and authenticating of identity may be tedious and time-consuming. Therefore, the convenience of mobile payments for daily micropayments is hindered.
Additionally, a mobile or wearable device is often used as an authorization factor, for example, by positioning the mobile device or by sending a one-time code to the mobile device. This allows recognizing and counteracting the credit card data theft and increasing security of mobile payments.
Wireless networks are by their very nature intermittent since you are never guaranteed to have a clear signal. And often, there are places where there is no connection at all. Wireless carriers typically charge for usage of their network by the byte, so it becomes important how much bandwidth is being consumed. And there are multiple networks now available to computers, such as wire-line LAN, WiFi (IEEE 802.11b and successors), Wireless Wide Area Networks (GPRS, 1×RTT), Bluetooth and even a serial cable between a PDA cradle and a PC.
Another new issue raised by the use of mobile computers is the management of the devices and assets on those devices. In the current philosophy of network and system management embodied by software such as HP OpenView and CA Unicenter, there is an assumption that network elements or nodes (eg. computers, routers, switches) are always connected to the network and rarely move. It is therefore straightforward to manage the elements using Simple Network Management Protocol (SNMP) and deploy or update software on those stationary devices. However, with devices that are mobile, there is a new set of issues. These mobile devices are not always connected and if they are, they may be connected to multiple networks and therefore have multiple IP addresses. They might be shared among a group of users (eg. truck drivers who take any arbitrary handheld computer when the start their rounds). The devices must be secure but not impose a heavy price by slowing performance or sending exponentially larger packets on expensive wireless networks.
It is therefore plain that one cannot simply extend the current networking philosophy to computing on intermittent networks. In order to deploy usable and cost-effective client-server solutions that are mission-critical on intermittent networks, the goals should be transactional guarantee and manageability.
Transactional guarantee means that the system must keep functioning regardless of whether there is connectivity or not. No messages should ever be lost but they should be kept in reliable persistent storage at each step so that they can be recovered should a failure occur in the system such as a power outage. The entire system, consisting of the mobile devices and servers, must always be in a consistent state. Even when a failure occurs, the transaction should be rolled back or otherwise compensated so that there are no conflicts in any application. An example of this is when a transaction is to be committed to two applications; if one succeeds and the other fails, the one that succeeded should be rolled back so that they are both consistent. Only when both have succeeded should the transaction be committed. The system should be performant and not allow a fault to throttle the entire system, ie. cause it to stop working or go into an infinite loop and consume a lot of resources. This can happen when a message is in a queue that is fails to be committed to a target application and continues to retry constantly; this is called a “poison message” and should be immediately taken off the queue and processed differently. It should also be very resilient to faults such as badly formatted messages so that the system does not need to be restarted when responding to problems.
Manageability encompasses security, asset management, software deployment and cost control. Security covers the usual areas of authentication, authorization, encryption and non-repudiation. There are many existing technologies that can meet these requirements. Mobile devices have additional requirement of remote locking when a device is reported lost or stolen. This can be done by sending a “poison pill” to kill the device and possibly destroy data or revoking the privilege to connect back to the server when it attempts to do so the next time a connection is available. Asset management refers to tracking the devices (eg. who owns it, where is it) and the management of the configurations on the device (eg. network settings, email settings). It is required that these are done set by a central system administrator and done automatically so that the user is not burdened to set up the configuration, which can be a complex and error prone process requiring much support. Another aspect of asset management is the ability to remotely run diagnostic test programs on the device. For example, the administrator might want to schedule the barcode scanner to be test every day and a report sent automatically when there is a connection so that he knows if the device needs to be brought into the office for maintenance. Software deployment is an area that has received a lot of attention because of the high cost of keeping the correct versions and license of software on computers. This problem is compounded for mobile devices that you cannot physically check. Software deployment configurations must be set up by the administrator remotely, whether the device is connected or not. When a device comes on line, it must automatically know which software to update. The administrator must also be able to specify which network to be used for software deployment. For example, use the free WiFi or serial connection to update software and only use the expensive wireless WAN for sending urgent application messages. Backing up data on the device is also a requirement for devices that have substantial disk storage such as laptops. Cost control is a new requirement for wireless devices where it does matter how much bandwidth is being used. Because wireless networks are more expensive, slower and intermittent, it becomes important for an application to determine which messages should be sent on which networks. Urgent and important messages should be sent on any available network. Less urgent and important messages should wait until a cheaper network is available. Other factors might come into play, such as system or network constraints. For example, if a satellite channel is available, only the most urgent and small messages might be sent. If the time is after 5 pm or the battery is low, perhaps the pending messages should be flushed immediately on any available channel.